Mar. 29. 2004 4:51PM 




ay S h a r r> e 




No. 0678 



P. II 



Application No. 09/894,090 
Amendment Dated March 29, 2004 
Reply to Office Action of January 29, 2004 



REMARKS 



This Amendment is responsive to the final Office Action mailed January 29, 
2004. Applicants respectfully submit that claims 1, 3-9, 11-13, and 15-18 as set forth 
herein patentably distinguish over the cited references, and ask for allowance of these 
claims. 

The current status of the claims 

Claims 1 v 3-9, 11-13, and 15-18 stand rejected under 35 LLS.C* § 102(e) as 
being anticipated by Ponnekanti et al. (U.S. 6,363,387, hereinafter "Ponnekanti"). 

THE PRESENT APPLICATION 

The present application addresses and overcomes certain deadlock situations 
created by concurrent transactions in a database having a unique key index. A 
deadlock condition may be created when, for example, two substantially simultaneous 
delete transactions involving different rows are followed up by two substantially 
simultaneous insert transactions that attempt to insert row data into the rows having the 
row identifications (RID's) of the deleted rows. 

In database systems utilizing pseudo-deletion of Index entries, a deadlock 
situation can arise if the two simultaneous insert transactions have index key values 
corresponding to the deleted rows. In this case, each insert transaction may acquire an 
X-lock for the pseudo-deleted index entry matching the other Insert transaction's key 
value to enter data into that row. Each insert transaction will also attempt to acquire an 
S-lock on the pseudo-deleted row having index key value corresponding to the index 
key value of the inserted data. This S-lock acquisition attempt is performed to verify that 
the pseudo-deleted row is actually deleted (that is, the delete has committed), so that 
the inserted row will have a unique key value. Each S-lock becomes blocked by the 
X-lock of the other insert transaction, thus causing deadlock. 

The deadlock occurs because the system Is unable to recognize that the 
blocking X-locks are not associated with the delete transactions, which have already 
committed. The present application overcomes this deadlock by providing: 

( 1 ) a new X-lock attribute, called a "Delete" attribute logically associated with the 



X-lock, that is set when an X-lock is granted to a Delete transaction; and 
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(2) a new Conditional S-lock, that is: 

a. not compatible with an X-lock with the lock Delete attribute set; 

b. compatible with an X-lock with the Delete attribute NOT set 
Specification at page 20 line 19 through page 21 line 4. 

The delete attribute element (1 ) is an attribute of a lock , and serves to distinguish 
the X-lock acquired by a delete operation from X-locks acquired by other types of 
operations. In FIGURES 4(B) and 4(C), the Delete element 450 appearing in the Lock 
Table is the new X-Iock delete attribute. The delete X-lock attribute (that is, element (1) 
above) is different from the pseudo-delete flag, such as the pseudo-delete flag 412 
shown in FIGURES 4(B) and 4(C). 

The X-lock delete attribute is distinguished from the pseudo-delete flag attribute 
of an index entry , which appears as the symbol "D n in the Index Table , See at least at 
page 16 lines 7-12. The delete X-lock attribute disappears when the X-lock is removed 
after the delete is committed; in contrast, the pseudo-delete flag 412 remains set even 
after the delete is committed. 

The new Conditional S-lock is conditional with respect to the delete X-iock 
attribute, and is granted when there is no X-lock or when there is an X-lock but that lock 
does not correspond to a delete operation (that is, the delete X-lock attribute is OFF). 
Thus, granting of the Conditional S-lock ensures that either there is no X-lock or, if there 
is an X-lock, then that X-lock is not associated with a delete operation. 

As noted in the specification at the bottom of page 20, the new X-lock attribute, 
called a "Delete" attribute is provided. The Delete attribute is logically associated with 
an X-lock in a manner that, as described on page 20, the Delete attribute flag or other 
indicia is set when the X-lock is granted to a Delete transaction. Further, a new 
Conditional S-lock is provided having specialized behavior relative to X-locks. The 
Conditional S-lock is not compatible with an X-lock whose Delete attribute flag is SET or 
ON. However, the Conditional S-lock is compatible with an X-lock whose Delete 
attribute flag Is NOT SET or OFF. Essentially, the new Conditional X-lock is granted 
when the previous X-lock requestor was not a Delete operation. Thus, support is 
provided in the specification for the amendments made to the claims above wherein the 
Delete X-lock attribute is logically associated with an exclusive X-lock. 
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THE PONNEKANTI REFERENCE 

Ponnekanti does not disclose a delete X-lock attribute logically associated with 
an X-lock. 

Ponnekanti does disclose a delete bit for index entries: "Each Index row employs 
a ROWJDELETE bit." Ponnekanti col. 12 lines 58-64 (underscore added). This index 
ROW_DELETE bit corresponds to the pseudo-delete index entry attribute disclosed in 
the present application. The index ROW DELETE bit cannot simultaneously 
correspond to the X-lock delete attribute . 

Ponnekanti also discloses a data ROWDELETE bit. Ponnekanti col. 12 lines 
34-37. The ROWDELETE status bit is associated with the row, and not with the X-lock 
obtained by the delete operation. This distinction is shown at col. 12 lines 36-57, which 
explain that a delete operation "sets the ROW_DELETE bit but the contents of the data 
row are left intact." Col. 12 lines 40-42. The ROW_DELETE status bit is reset when a 
subsequent transaction locks onto the row, at which time the now delete bit can be 
removed. Thus, the ROWDELETE status bit remains after the delete operation's X-lock 
is removed - it therefore cannot be associated the X-lock of the delete operation . 

This is further shown at Ponnekanti col. 13 lines 31-51, which describes the use 
of a "lock instant." The "lock instant" appears to correspond to the unconditional S-tock 
of the present application, and Is used "to see whether there exists a conflicting lock 
already held on the row." Col. 13 lines 36-38. When a "delete" status bit is found, the 
"lock instant " is requested. If no conflicting lock is found, then the "lock instant" is 
granted and the operation issuing the "lock instant" knows that the delete operation has 
been committed. Col. 13 lines 38-40. This further demonstrates that the delete bit is neJ 
a lock attribute - it may be that the delete bit is set even though there is no lock on the 
row. 



and is queued (i.e., sleeps) until the conflicting lock is removed. Col. 13 lines 46-48. 
This is the normal operation of an unconditional S-lock when a conflicting X-lock is 
already applied. There is no disclosure or fair suggestion to provide a lock attribute of 
the X-lock to identify whether the conflicting lock was issued by a delete operation. 
Without such an X-lock attribute, the system cannot tell whether an X-lock conflicting 
with the unconditional S-lock is due to a delete operation or some subsequent 



On the other hand, If a conflicting lock does exist, the "lock Instant" fails, 
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operation, such as another insert operation. Two insert operations attempting 
substantially simultaneous S-locks can thus be deadlocked, and this deadlock is not 
overcome by PonnekantL 

As noted by the Office Action, Ponnekanti also uses the expression "conditional 
lock request." However, this conditional lock request Is entirely different from the 
Conditional lock request disclosed in the present application. 

Ponnekanti defines an unconditional lock request and a conditional lock request. 
In the case of an unconditional lock request that requests a lock on an already locked 
now, the unconditional lock request is queued (i.e., sleeps on the lock) until the other 
transaction releases its lock. Ponnekanti col. 1 1 lines 36-41 . In the case of a conditional 
lock request that requests a lock on an already locked row "the Lock Manager returns 
LOCKJ3IDNTQUEUE status and does not grant the lock." Ponnekanti col. 1 1 lines 42- 
44. 

The "conditional" aspect of Ponnekanti's conditional lock request resides in 
whether or not the lock is granted. If a conflicting lock exists, the conditional lock is not 
granted. In contrast, Ponnekanti's unconditional lock request is always granted, 
although it may be queued until a conflicting lock releases. In contrast, the Conditional 
lock of the present application is conditioned on whether a conflicting X-lock has its 
Delete attribute OFF. 

To summarize, Ponnekanti does not disclose the Delete X-lock attribute of the 
present application, which identifies an X-lock as associated with a delete operation. 
Ponnekanti also does not disclose the Conditional S-lock of the present application that 
Is granted if a conflicting X-lock has its X-lock delete attribute not set. As a result, 
Ponnekanti does not resolve the deadlock situation illustrated, for example, in 
FIGURES 3(A)-3(F) of the present application, because the conditional S-lock of 
Ponnekanti cannot distinguish between an X-lock of a delete operation and an X-lock of 
another operation. 

Claims 1-6 patentably distinguish over the cited references 
Claim 1 has been amended to call for the exclusive X-lock to include a Delete 
logically associated therewith, a SET state of the Delete X-lock attribute being indicative 
of a transaction holding the X-lock being a delete transaction. Claim 1 has been further 
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amended to incorporate the subject matter of canceled claim 2 directed toward the 

Conditional S-lock. Specifically, amended claim 1 calls for. 

an unconditional S-lock that enables shared access to the first 
table element and Is selectively assigned by the lock manager to the first 
table element only when the first table element Is without an exclusive X- 
lock previously assigned thereto; and 

a conditional S-lock that enables shared access to the first table 
element and is selectively assigned by the lock manager to the first table 
element only when the first table element is either without an exclusive X- 
lock previously assigned thereto or is without an exclusive X-lock having 
its Delete X-lock attribute SET assigned thereto. 

Although Ponnekanti discloses conditional and unconditional S-locks, these elements 
are wholly different from what is called for in amended claim 1. In Ponnekanti, the 
"conditional" S-lock is conditional in that if an X-lock exists, the conditional S-lock is 
simply not granted. There is no disclosure in Ponnekanti of a Delete X-lock attribute, 
much less of a Conditional S-lock whose granting is conditioned upon either the 
absence of a conflicting X-lock or the absence of a conflicting X-lock having its Delete 
X-lock attribute SET. 

For at least these reasons, Applicants respectfully submit that claim 1 , as well as 
claims 3-6 that depend therefrom, as set forth herein are in condition for allowance and 
request an early indication of allowance of these claims. 

Claims 7-9 patentably distinguish over the cited references 
Claim 7 has been amended to call for requesting a Conditional S-lock on a table 
row indexed by the pseudo-deleted table Index entry, said Conditional S-lock having 
compatibility characteristics respective to an X-lock: 

the Conditional S-lock not including compatible with 
an X-lock having a Delete attribute logically associated with 
the X -IO C k that is SET or ON, and 

the Conditional S-lock being compatible with an X-lock having a 
Delete attribute that is NOT SET or OFF. 
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Ponnekanti does not disclose a conditional S-lock having these 
characteristics. Rather, what Ponnekanti calls a conditional S-lock is granted 
conditional upon whether there is any conflicting X-lock, not on the attributes of 
the conflicting X-lock. 

Claim 8 sets forth that step of receiving an indication that the Conditional 
S-lock is granted includes the steps of: 

granting the Conditional S-lock conditional upon the table row indexed by the 
pseudo-deleted table index entry not having an X-lock assigned thereto; 

granting the Conditional S-lock conditional upon the table row indexed by the 
pseudo-deleted table Index entry having an X-lock assigned thereto wherein said X-lock 
has its Delete attribute not set, reset, or off; and 

receiving an indication that the Conditional S-lock is granted conditional upon the 
granting of the Conditional S-lock. 

Claim 8 specifies that the Conditional S-lock is granted in the case where the 
X-lock assigned thereto has its Delete attribute not set, reset, or off. In contrast, 
neither the conditional nor the unconditional S-lock of Ponnekanti is ever granted 
when an X-lock is also present - In the conditional case, a conflicting X-lock in 
Ponnekanti simply causes the conditional S-lock to fail, whereas in the unconditional 
case a conflicting X-lock in Ponnekanti causes the S-lock to be queued (or to 
"sleep/' as Ponnekanti puts it). 

For at least these reasons, Applicants respectfully submit that claims 7-9 as set 
forth herein are in condition for allowance and request an early indication of allowance 
of these claims. 

Claims 11-13 patentably distinguish over the cited references 
Claim 11 has been amended to call for requesting a Conditional S-lock on a 
table row indexed by the pseudo-deleted table index entry, said Conditional S-lock 
being incompatible with an X-lock acquired by a delete operation and being 
compatible with an X-lock not acquired by a delete operation based on a Delete 
attribute logically associated with the X-lock . The conditional S-lock of Ponnekanti 
does not distinguish between an X-lock acquired by a delete operation and an 
X-lock not acquired by a delete operation. As a result, under certain circumstances 
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the database of Ponnekanti can experience deadlock if an S-lock applied to verify 
that a delete operation has committed is blocked by an X-lock applied by an 
operation other than the Delete operation. In contrast, by using the Conditional 
S-iock as called for in claim 1 1 such a deadlock does not arise, because the 
Conditional S-lock recognizes that the conflicting X-lock was not acquired by a 
delete operation. Hence, the delete operation must have committed, and so the 
Conditional S-lock is granted. 

Claim 12 further distinguishes over Ponnekanti, which does not disclose or fairly 
suggest granting the Conditional S-lock conditional upon the table row indexed by the 
pseudo-deleted table index entry having an X-lock assigned thereto wherein said X-lock 
has a Delete attribute that is not set, reset, or off, as called for in claim 12. 

For at least these reasons, Applicants respectfully submit that claims 1 1 -1 3 as 
set forth herein are In condition for allowance and request an early indication of 
allowance of these claims. 



Claim 15 calls for a lock manager for use in a database management system 
(DBMS) managing a database application including a database having at least one 
table and cooperative with an index manager and a data manager for restricting 
access to a first table element of said at least one table by assigning one or more 
locks thereto including at least an exclusive X-lock that enables exclusive access to 
the first table element, the exclusive X-lock including a Delete attribute logically 
associated therewith, a SET state of the Delete attribute being indicative of a 
transaction holding the X-lock being a delete transaction. 

Ponnekanti does not disclose an exclusive X-lock including a Delete attribute 
logically associated therewith In which a SET state of the Delete attribute is 
indicative of a transaction holding the X-lock being a delete transaction. By Including 
a delete X-lock attribute as called for in claim 15, a subsequent insert transaction 
can determine whether or not an X-lock on a pseudo-deleted row means that the 
delete transaction has not yet committed. 

Claim 16 calls for the lock manager to be adapted to restrict access to said 



Claims 15-18 patentably distinguish over the cited references 
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first table element by assigning a Conditional S-lock that enables shared access to 
the first table element and is selectively assigned by the lock manager to the first 
table element only when the first table element does not have an X-lock with its 
Delete attribute In a SET state assigned thereto. Ponnekanti does not disclose a 
Conditional S-lock with the behavior called for in claim 16. 

Claim 18 calls for the lock manager to be operative to grant the Conditional S- 
lock on the table row corresponding to the existing index key entry only when the table 
row is without an exclusive X-lock assigned thereto, or the table row has an exclusive 
X-lock assigned thereto with its Delete attribute not in said SET state, to enable the 
index manager to update the table index key entry with the new row identification RID, 
release the Conditional S-lock on the table row corresponding to the existing index key 
entry, and reset the pseudo-delete flag to and OFF state. Ponnekanti does not disclose 
granting a conditional S-lock when the table row has an exclusive X-lock assigned 
thereto with its Delete attribute not in said SET state. Indeed, Ponnekanti does not 
disclose a Delete attribute of an exclusive X-lock. 
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CONCLUSION 

For the reasons set forth above, it is submitted that all claims 1 , 3-9, 11-13, and 
15-18 as set forth herein patentably distinguish over the references of record. 
Allowance of all claims and an early notice to that effect is respectfully requested. 

Respectfully submitted, 

FAY, SHARPE, FAGAN, 
MINNICH & McKEE, LLP 

Date Michael E. Hudzinski 7/ 
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